Sprint Grading Notes

Point allocation for grading of Sprints 1-5 comes from four areas: planning/documentation, completeness/correctness, code quality/refactoring and teamwork. Teams will receive a numeric score out of 100 on each sprint, individual grades may be higher or lower based on scores on team evaluations and individual contributions to the project.

Planning

A relatively small portion of points for each sprint (20 points) is dedicated to Scrum planning and project documentation using Microsoft's Azure DevOps. These should be easy to earn - carefully read each of the Mario PBIs to come up with Both the Effort for the Story along with a series of tasks to accomplish for the sprint, estimate the time needed to complete the task (either in hours or days - as a team pick one of those units and be consistent), and update time remaining on tasks as work is done over the course of the sprint. The Description of each task should detail from the Assigned Developer's perspective HOW they will be accomplishing the WHAT that was described in the Associated PBI.

Completeness/Correctness

A slightly higher portion of points for each sprint (30 points) is dedicated to the correctness of the deliverable. Each sprint has a set of Target PBIs (ex: support for drawing all sprites in the game and handling controller input), each with a relative weight based on the difficulty of the story (as determined by the instructor). Points are earned based on how complete/correct the story is implemented (does the implementation satisfy the Acceptance Criteria?). (Mario/block collision detection and response is used as an example for the following grading rubric).
  • The feature is fully functional, but not necessarily in the exact same way as it was in the original game - 100% [ex: Mario doesn't get stuck in blocks but hovers 1 pixel off of the ground]
  • The feature is mostly functional, with one or two erroneous use cases - 75% [ex: Only when running at full speed, Mario can move into a block and get stuck]
  • The feature is partially functional, with several erroneous use cases - 50% [ex: At any speed, mario can move into a block and get stuck]
  • The feature is mostly not implemented - 25% [ex: Mario can pass through blocks but a collision detection message is written to a log file when he is intersecting]
  • No implementation - 0%

Code Quality/Refactoring

The largest portion of points for each sprint (40 points) is dedicated to code quality. You start with full credit and lose points for flaws in code quality. Here are some problems/code smells that I will be looking for when grading code quality. Occasionally violating one of these does not mean a design is bad, but this is what you should strive for.
  • Long methods (30+ lines)
  • Excessive Branching (2+ levels deep in one method)

  • Long classes (100+ lines)
  • High coupling of a class
  • Low cohesion of a class or method
  • Non-descriptive class, field, and method names
  • Public fields, properties, and methods that should be private
  • Inappropriate intimacy
  • Dead code and unused fields and methods

  • Duplicated code
  • Magic numbers and strings

Teamwork

(10 points)
  • Did all of the team members provide a high-value code review of code introduced during this Sprint?
  • Did each of the team members contribute to the Sprint (review of task assignments, Code contributions, ...)
top